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A secure sharing of resources betw een appUcations in independent e:^ectttion environments 
in a portable device (e.g* smart card) 

Integrated Ckcoit Cards (IC cards or 'smait cards') are intrinsically secure computing platfonhs 
5 ideally smted to providing enhanced security and privacy function^Oity to applications. They are 
also bdng used in the Wireless phones, and other con>innnication devices, as a place to store user 
sobscxiption data. User private keys and other private or confidential data. They prox'ide a mean 
for secure storage and con^uUtional faciHties for sensitive information such as: 

♦ Pdvate key$ and key fragments- 
XO • Accotmt numbers and stored value. 

♦ Passwords and shared secrets- 

♦ Autiiorizadons and peimisaons. 



At the same time, x&any of these tokens provide an isolated processing facility capable of using 
15 this information mthout exposing it within die host environment where it is at potential risk from 
hostile code (viruses, Trojan horses, and so on). Tliis becomes cridcally important for certain 
Operations such as; 

• Generation of digital signatures, using private keys, for personal identification 

• Network authsnticadon based on shared se^ts. 
20 • Maintenance of electronic representadons of value. 

• Portable permissions for use in off-line situations. 

Cuireat sm^ cards use the communicadoa protocol defined in die ISO 7816 standards by which 
an asynchronous protocol is being used and APDU commands cairy application level 
25 inforaiation. This protocol is also being used in mobile phones, and the GSM and 3GPP standards 
conform to it. 

Today there are additional and more rapid synchronous communication protocols dial axe being 
integrated in new smart cards. This aUows the addition of a synchronous communicadon protocol 
(e.g. USB or oflier), in parallel to the ISO 7816 communication protocol. Since each 
30 commtiaication channel uses a different set of pin contacts there are no inter-dependencies 
between the two. 

Today the terminal (phone or other communicadon de^dce) uses fhe smait card services by 
sending specific commands (called APDU commands) that invoke different computation services 
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or cause tiie retrieval of data. The smart card application performs tlie request and returas the 
needed data. 

New cards integrate an additional and independent communication protocol (e.g. USB) on a 
different set of pin contacts of the card. In this case the card manages the two communication 
channels by tv^'O independent processes. 

The above card interface can be managed by defining two virtual execution environinents; 

• AFDU execution environment 

• New execution environment 

The "APDU executiott <?nYiroiiinent" is the existing (legacy) execution enviraranent to which all 
existing standards apply, Foi example, for the SIM card, it concems all the standards that define 
the appHcaUons and services that the card ii^pl^ents for network authentication, SIM-TooMt 
applications etc. 

The "New execution environment" is independent of the old one ("APDU execution 
environm^'*) and does not have any comiaunicaUon with it. This is important in order to assure 
that cmrent card applications are not hdmg affected. This backward compatfcility need imposes a 
sejaration (fire-walhng) between applications in the two execution environinents. These 
execution esnviromnents can be illustrated in figure 1, 

The "New execution environment" can allow tihte execution of several applications, as is the case 
for the "APDU execution environment". An example is a Web server that may integrate sev^ 
web applications. 

The "New execution environment*' can implement a new set of applications that are independent 
of the legacy implications m the "APDU execution environment". However, the card issuer may 
want to allow a certain level of shaiing of data and operating system services that will not 
interfere with the behavior of the legacy environment ("APDU execution environment"). A 
commmucation protocol between applications in the tw-o execution enviiranments may also be 
implemented in order to allow a secure siiaiing of data or ftinctions. 

This principle can be extended to more than two protocol stacks. Even if the portable dex'ic© has 
only two phy^cal layers, these last ones can be shared between several protocol stadks. 

Jn a particular case, a physical layer can pro\oide a support for several logical channels (or 
''pipes"). So, to illustrate this concept, the USB protocol is able to support sevesral logical pipes 



(end points) on the sm^ physical medium. Some logical pipes cm be dedicated to a protocol 
stack and some others to another one. The concept is named " composite device" within the USB 

environxneni- 

Through the same USB comiector, the host can manage several types of device (e.g. mouse, 
5 keyboard). 

The concept applied to a smart card able to host an USB intexface can take advantage of the 
invention. Through this USB Jayex, we can imagine host at tiie card leveh 

■ A TCP/IP stack 
10 "A mass storage stack 

Beside this USB coinmunication, the smart card uses the regular IS07816 protocol to estabUsh 
anotlier link of conunnnicadon. This example shows that at least three difEereni protocol stacks 
can mn m the same smart card. So, the invention is applicable where in each speciiic context, an 
15 application can estabUsh a secme and controlled bridge between execudon environments runnmg 
different protocol stacks. 

More genea-ally, the portable device can be a smart card or any secure portable device able to host 
at lea^t oxxe physical chamxel of coxxwnunication and wheareiti at least one logical channel of 
20 comsmrtication can be opened. The unique condition is to host at least two logical channels of 
coxnmunication whatev^sr is the nunabox of physical channel of communication/Consequently, the 
Jnvention can be usefully used vdthixk smart card tuxxmng an ISO 7816 protocol but with multiple 
logical channels or with a Mnlti Media Card or a dongle Ce.g- USB dongle). 

25 The invention is also applied, but not litoited to, the foUo-vting scenarios, which illustrate well the 
ability to have a combination of independent physical and logical conimunication channels: 

• A portable device that has one USB conraiunication channels but with several logical 
cliannels (**pipes*0 whei*e APDU commands are sent on one logical channel, to address 
tlve legacy applications^ and a TCP/IP protocol Stack runs on the other logical channel. 
30 •A portable device that has one or more physical or logical channels, each associated with 

a difiterent isolated execution environment. The physical communication channels can hQ, 
but are not limited to, the following examples: 
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o Multi Media Memcary card (MMC) protocol 

o SPI (Serial Peiiphearal foterface) protocol 

o USB protocol 

o Smart card comactless protocols 

5 o ISO 7816 protocol 

o ISO (FCD) 15693 protocol 

o ISO 14443 protocol 

o The coimrcutiication protocol defined in the TS 102.221 standai-d 

10 Tlie sharing of data a^xd operatmg system services between the multiple execution environments 
may rely on sevts^al mechanisms and we consider only one couple in a set of couples: 

• A pipe between two applications in the two exefcution environments when one i& the data 
producer and the other is the data consumer 

♦ A file shaiing when One application has read access to a file and the other has a read/write 
access to the same file (sort of implementation of a pipe when one application is the 
pto(iacex and the other is the consumer) 

♦ A communication protocol that is defined and implemented internally by the card 
Operating System and is shared by the two applications 

• Sharing of re-entrant fimctions and function libraries of the card operating system 
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See figure 2 illustrates the mteractions between the two execution envhronmeuts: 



Figure 2, App2 in the "New execution environment" can sh^ information and/or services with 
App A & B in the "APDU execution environment*. The appHcadons are not necessarily active at 
25 the same time. It may be that App A and/or App B were invoiced and produced some data that 
may then be used by App 2 when it starts to run. 

The smart card underhning operating system offers the resom^ and data sharing mechanisms of 
ilie following typ&s: 

• File sharing controlled by Access Control List (ACL) 

• Stream based communicatiaa (datapdpe) cantroHed by Access Control list (ACL) 

• Proprietary communication mechanisms between applications which satisfy the foHowiag 
chaiactenstics: 
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o Enables to s&nd and receive data between two applications ruitidng in two 

different execution emiromnents 
O Tbe access to this couanmnication mechamsm is controlled by Access Control 

List (ACaL) 

. Re-entrant functions that are published by shared libraries in the card underlining 
operating system 

• Re-eatrant liinctions that are published by an appUcation running in one execution 
environment to an appKcation running in ih& other execution environment (e.g. RPC like) 

Access Control List (ACL) 

Access Control List (ACL) is a mean to identify an application, or tiie entity chat invoked the 
application, and attach access rights to it. An ACL can be represented as a pair of the following 
items: 

<id, access conditions> 



The id can be one of the following: 

m Application id in the execution environment 

• User id for v<rhom the application is perfoiming a task 

• External entity for who»3L the application is perfonxmg a task (e,g. card administrator or 
20 super user) 

The access conditions may be, but not limited to one of ttie following: 

• Read 

• Write 
25 • Execute 

• Any combination of the above 

The card operating system may offer shared resources to the two execution environments. An 
applicadon will have access rights to use tixe shared resources, if there is an ACL that defines its 
30 access rights to it. The shared resources may be a commnnication mechanism between the two 
execution environments or be a set of shared functions. Each application may be granted the 
rights to use tlie shared resources if it satisfies the corresponding access conditions (ACL) 
attached to each resource. 
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Card administrator role 

The ACLs are defined by an entil^y that is called card adniitiistratoi. Nonaally, tins is the card 
issuer or "saper user". This entity csm define and change ACLs in the card for the sharing of 
resources between the execution environnieats- 
5 The identity of the *'saper user" is nortnaily proved by cryptographic means that provide a j«roof 
of possession of an administrator key. 

Example l 

ILets take the example of a SIM card which also has the additional "New execution envixonment". 

10 The SJM card implenaents all the services that are defined in the related GSM standards and they 
an ran in the AEDU execation environment The APDU execution daiviromnent communicate 
with the mobile phone via the ISO 7816 and GSM standardized protocols. 
The "New execution environment" communicates with the mobile phone via a USB protocol witfa 
TCP/IP and HTTP on top, and runs an HTTP web server with an application that can peifoim the 

15 following task: 

• Receive itifoimation about a content that is installed in the mobile phone 

• Con^te the pennissions to execute a content that is installed in the mobile phone (a 
Digital Rights managacnent application) 
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For Oris purpose the application needs to get a Ucense information from a file. This license was 
updated in the card via an OTA message (Over the Ak protocol), which is a protocol thai is 
defined in the GSM standards. An appUcadon that was running in the APDU execution 
environment received this message and updated the file accordingly. The GSM application can 
update the file since there is an ACL that gives it a read-wiite permission to this file. 
In order to get the Ucense information the Web appUcalion in the "New execation enviromnent" 
reads die shared file in which die license is stored. The application can read die shared file since 
diere is an ACL for it that gives it a read-only permission to this file. If it wiU try to also write to 
this file the operating system will not allow it and wiU throw an exception. 
The Web appHcadon that runs in the "New executitm environment" also needs to perfomi a 
decryption of ihe content that needs to be rendered ia the mobile phone. For that it needs to access 
a library that performs this decryption and that uses a key that v^as personalized in the card duiin- 
manufacturing or updated OTA (Over the Air protocol). This appHcafion can execute the decryp'I 
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fuTOCtion in the decryption library since tliere is an ACL that gives it an ^'execution" permission" 
to this sbated function^ 

See fignre 3. 

5 

The above 15gure illustrates the communication mechanisxas between the two applications. The 
dotted lines indicate tliat the applications can exchange data between them or shaie some 
cotXMcnon functions. The actual communication of the data is done by file shaiing or by calling 
shared libraries that are implemented by the operating system. 
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CMms: 



1. A portable device comprising: at least one physical channel of communication to at least 
one apparatus wherein each physical channel of communication can host at least one 
logical channel of communication (pipe) and for each logical channel is associated a 
secuire/independem execution etivifonment when more tlien one logical channel is beincr 
used. 

2. A portable dence as recited in the claim 1 wherein tlie portable is a smart card. 

3. A portable device as recited in the claim 1 wherein the portable is a MuM Media Memory 
card, 

4. A portable device as recited in the claim 1 wherein the apparatus is a mobile handset 

5. A portable device as recited in the claim i wherein the apparatus is a personnel computer, 

6. A portable device as recited in the claim 1 wherein at least one of the physical channel of 
communication uses the USB parotocoL 

7. A portable de vice as recited in the claim 1 wherein at least one of the physical channel of 
communication uses the SET protocol 

8. A portable device as recited in the claim 1 wherein at least one of the physical channel of 
25 communication uses the MMC protocol 

9. A portable device as recited in the claim 1 wherem at least one of the physical channel of 
communication uses a protocol for contactless smart card 



10. A portable device as recited in the claim 9 wherein the protocol of communication is 
defined in tlie ISO (FCD)15693 

11. A portable device as lecited in the claim 9 wherein tlic protocol of commuaication is 
defined in the ISO 14443. 
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12. A portable device as recited in tiie claim 1 wherein at least one of the physical channels 
of cottimuwcation uses the protocols defined in the TS 102. 2Z1 standard, 

5 13, A portable device as recited in the claim 1 wherein at least one of the physical channels 

of communication uses the protocols defined in the IS07S16 standard. 

14, A portable device as recited in tlie claim 1 wherein eadi physical channel is independent 
of the others. 

10 

15- A portable device as recited in the dLaim 1 and at least one of the claims ft'om 2 to 14 
wherexD fo^r execution environments for each of the logical communication channel; with 
applications that can be executed independendy in each execution environment^ in an 
isolated manner from ihe other execution environment but with some resources that can 

15 be shared between applications, in the different execution environments, based on access 

condition lists (ACLs). 

16- A portable device as recited in claim 1 and 15 for which the resource that can be sfaiired 
between applications in the different execution environments is a shared file for which 

20 access conditions (ACLs) are defined for the appKcations that can access it to specify the 

rights of the applications to peiform operations on this file (e g. read, write etc,)- 

17. A portable device as recited in the daim 1 and 15 for which the resource that can be 
shared between applications in the different execution environments is a shared object 
25 called "pipe" on which it is possible to write data in a "first in first out" (FIFO) manner 

and for which access conditions (ACLs) are defined for the applications that can access it 
to specify the rights of the applications to perform operadons on this pipe (e*g. put, get 
etc.). 

30 18. A portable device as recited in the claim 1 and 15 for which the resom'ce that can be 

shared between applications in the different execution environments is a shared funcdon 
that is implemented by tlie underlining common operating system and for which access 
conditions (ACLs) are defined for the applications that can access it to specify the rights 
of the application to invoke it. 
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19. A portable device as recited in the claim 1 and 15 in which an appUcations in an 
execution enviroaments can share some functions with an application in anothear 
executioa environment by allowing the other application to invoke these functions and 
where access conditions (ACLs) ate defined for the application ttiat can access this shared 

ftcnctions. 
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Figure 1 



Smart card shared opex^ating system 
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Smart card shared operating system 
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Figure 3 



Smait card shared operating system 
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